Minimal Viable Plasma
m0t0k1ch1.icon 基本的な仕様については上記の実装を見た方が早いのでここでは取り上げない
---.icon
子チェーンが満たすべき要件
What are the requirements for a sidechain to operate under MVPlasma?
mewwts：Minimal Viable Plasma に従って運用される子チェーンが満たすべき要件は何？
It must be organized either in a UTXO model of the sort that I describe in this spec, or an account-based model where every account has a defined “owner” and any change to an account state (even “positive” changes like balance increases) requires the owner to sign off. A finality-bearing consensus algorithm would also be ideal.
vbuterin：
UTXO ベースのモデルの場合
この議論の冒頭で自身が提案した仕様に基づいたもの
アカウントベースのモデルの場合
全てのアカウントに「所有者」が存在する
アカウント状態のあらゆる変更は所有者の承認が必要（残高増のような「ポジティブな」変更であっても）
また、ファイナリティのあるコンセンサスアルゴリズムが理想。
アカウントベースのモデルで送金を行う場合、例えば以下のようになる。
1. Bob sends a transaction that (i) decrements his balance, (ii) creates an “unfinished operation” sending money to Alice. This gets includes in the plasma chain, and then Bob signs a confirmation.
2. Alice sends a transaction that (i) consumes the unfinished operation, (ii) increments her balance. This gets includes in the plasma chain, and then Alice signs a confirmation.
vbuterin：
1. Bob
以下のようなトランザクションを送る
自身の残高を減らす
Alice への送金に対応する unfinished operation をつくる
Plasma チェーンに取り込まれたら、確認の署名を行う
2. Alice
以下のようなトランザクションを送る
unfinished operation を消費する
自身の残高を増やす
Plasma チェーンに取り込まれたら、確認の署名を行う
m0t0k1ch1.icon 端的に言うと、2 フェーズに分割すればよいと
m0t0k1ch1.icon Alice が受け取らなかった場合など、unfinished operation の扱いがめんどくさそうなシーンはありそう
---.icon
state channel との比較
This looks completely like state-channels with a centralized hub. Would you please explain this reasoning for me and everyone in this thread in some more details?
shamatar：中央集権的なハブを用いた state channel と完全に同じように見える。この理由をより詳細に説明してほしい。
m0t0k1ch1.icon 「この理由」というのは、「2 段階なトランザクション処理が必要な理由」
Not the same thing. With (naive) state channels with a centralized hub, if you have N parties with C total coins, then there needs to be N * C collateral for the system to work, as you need a channel with C coins locked up for each user, but with plasma you can do it with C collateral. You can probably reduce the N * C greatly with some metachannel scheme; Jeff Coleman can probably think up of a way to do that better than myself, but with Plasma even the simple version is optimal. The tradeoff is that with state channels in the happy case users can withdraw instantly, whereas in Plasma this can’t happen except through third-party intermediaries that are willing to buy an exit slot in progress. So it’s aimed at somewhat different sets of use cases and tradeoffs.
vbuterin：同じではない。中央集権的なハブを用いた state channel において、それぞれ総量 C のコインを保有する N 個のグループを仮定した場合、システムが稼働するためには N * C の担保が必要。つまり、ユーザーごとに C をロックアップしたチャネルが必要。一方、Plasma は担保が C あればいい。何らかのメタチャネルスキームを用いて N * C の担保を減らすこともできるだろう（Jeff Coleman であればより優れた方法を考え出すことができるだろうが、Plasma は単純なバージョンであっても最適化されている）。トレードオフとして、state channel では、問題が起こらなければユーザーが即座に引き出しを行うことができる。処理中の exit スロットを購入したいサードパーティが仲介するような場合を除いて、Plasma でこれは起こりえない。つまり、Plasma はユースケースやトレードオフの異なるパターンを目指したもの。
---.icon
発展的な議論
m0t0k1ch1.icon 1 ページが肥大化してしまうのでトピックごとに分割
---.icon
その他